Data integrity for proximity-based communication

ABSTRACT

Methods, systems, and computer programs for trusted communication among mobile devices are described. In some aspects, an authentication value is generated at a first mobile device based on a message and a shared secret value stored on the first mobile device. In response to detecting proximity of a second mobile device, the message and the authentication value are wirelessly transmitted from the first mobile device to the second mobile device. In some implementations, the message and the authentication value can be wirelessly transmitted by a proximity-activated wireless interface, such as, for example, a Near Field Communication (NFC) interface.

BACKGROUND

This specification relates to data integrity for proximity-basedcommunication.

Some mobile devices include a near field communication (NFC) chip thatenables the mobile device to communicate wirelessly with otherNFC-enabled components. For example, tapping an NFC-enabled mobiledevice to a passive NFC tag can cause the NFC tag to wirelessly transmitdata to the mobile device. In some instances, mobile devices cancommunicate directly with each other using NFC technology, for example,in a peer-to-peer mode.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a schematic diagram of an example communication system.

FIG. 1B is a schematic diagram of another example communication system.

FIG. 2 is a schematic diagram of an example mobile telecommunicationdevice.

FIG. 3 is a signaling and flow diagram showing an example technique forcommunication among devices.

FIGS. 4A-4C are signaling and flow diagrams showing example techniquesfor establishing a shared secret among devices.

Like reference numbers and designations in the various drawings indicatelike elements.

DETAILED DESCRIPTION

Users who have multiple devices, such as a smartphone and a tablet, maywant the ability to view content or execute actions on either device ina seamless way, for example, without having to acknowledge or confirminteractions between their devices. As a particular example, a user mayreceive a link on a smartphone and want to open the link on the largerdisplay of a tablet device. As another example, a user may view a phonenumber (or the name of a contact, or other information associated with aphone number) on a tablet device and want to initiate a call to thephone number using their smartphone, which has access to atelecommunication network. As yet another example, a user may view aphone number (or the name of a contact, or other information associatedwith a phone number) on a handheld device and want to initiate a call tothe phone number using their speakerphone, which has wireless orlandline access to telecommunication network.

More generally, users may want their devices to trust each other, forexample, so that their devices can interact seamlessly and allowapplications to run on the best-suited device. Similarly, multipledifferent users may want their devices to trust each other, for example,so that the users can seamlessly share content or other types ofinformation. For example, users may want their devices to communicatewithout repeated pairing, confirmation steps, syncing steps, or otheroperations that can interrupt the user experience. Moreover, manydevices include proximity-based wireless communication modules, andusers may want their devices to seamlessly exchangeapplication-independent messages, while taking advantage of theproximity-based wireless communication features available on theirdevices.

A trust mechanism can be established between devices so that the devicescan automatically verify integrity of wireless communications, forexample, without requiring user acknowledgment or confirmation. Forexample, eliminating user acknowledgment or confirmation steps forwireless interactions, without additional countermeasures in place, canrender a device vulnerable to certain types of attacks, for example,launched by non-trusted devices.

In some implementations, trust can be established among devices based ona secret value shared by the devices. The shared secret can be used toverify integrity of messages received from other devices, for example,messages received by proximity-based interactions. Moreover, the sharedsecret can be used to verify the integrity of messages independent ofthird party certification. For example, in some instances, once theshared secret is established on the devices, the shared secret can beutilized without reference to a certificate authority or otherconventional Public Key Infrastructure (PKI) paradigms.

One example of proximity-based communication is provided by Near FieldCommunication (NFC) technology. In some implementations, NFC technologyenables data exchange between devices at a distance of approximatelyfour to ten centimeters, at rates of approximately 100 kbps. NFC-enableddevices can be made to transfer information between devices by simplyplacing them near each other. For example, “tapping” or otherwisebringing two NFC-enabled device within range of each other may cause oneor both of the devices to send a message to the other device.

Some NFC-enabled devices include passive components. For example, someNFC tags operate passively, utilizing power received wirelessly from anactive NFC device. Accordingly, some NFC devices can operate in alistening mode or another passive mode of operation. An NFC deviceoperating in a listening mode can receive wireless signals transmittedby other NFC devices. The listening NFC device can respond bytransmitting a signal that allows the other NFC device to detectproximity of the listening NFC device. The response can be generatedbased on energy extracted from the signal received by the listening NFCdevice, energy stored at the listening NFC device, or energy from othersources.

Some NFC-enabled devices include active components. For example, someNFC devices have an internal power source or they can be integrated intoa device (e.g., a smartphone, a tablet, etc.) having an internal powersource. Such active devices can operate in a listening mode as outlinedabove. Additionally or alternatively, an active NFC device can operatein a polling mode. An NFC device operating in a polling made can sendperiodic polling signals or other interrogation messages that allowother NFC devices to detect proximity of the polling NFC device. Thepolling NFC device can detect proximity of other NFC devices, forexample, when the other NFC devices respond to the polling signal.

NFC-enabled devices communicate with each other wirelessly byelectromagnetic signals. For example, some currently availableNFC-enable devices utilize radio frequency signals at or near 13.56 MHz.Whether two NFC-enabled devices detect proximity of each other can be afunction of the effective range of their NFC modules and other factors.In various contexts, the effective range at which NFC modules can detecteach other may depend, for example, on the power and frequency of thesignals transmitted, the transmission environment, the orientation ofthe devices, and other considerations. For example, a listening NFCdevice may detect proximity of a polling NFC device when the listeningNFC device receives a signal having a signal-to-noise ratio greater thana threshold level. Similarly, a polling NFC device may detect proximityof a another device when the polling NFC device receives a signal havinga signal-to-noise ratio greater than a threshold level. Different NFCdevices may have different effective ranges, and they may have differentthresholds for detecting proximity of other devices. Moreover, proximitycan be detected based on additional or different criteria. In someexamples, NFC-enabled devices are configured to detect proximity ofother NFC-enabled devices within a range of about four to tencentimeters. NFC-enabled devices can potentially be configured to detectNFC-enabled devices, or other types of devices, in a different range.

In some implementations, a device may detect proximity of another devicebased on additional or different techniques. For example, a device mayinclude an accelerometer, a directional coupler, or a combination ofthese and other components that enhance proximity-detection featuresprovided by NFC or another type of proximity-based wirelesscommunication technology. In some instances, a device can detectproximity of another device based on physical contact between thedevices. For example, some devices may include sensors that detectproximity of another device based on non-conductive contact (e.g.,“tapping”), conductive contact (e.g., wires or leads), or another typeof conductive or non-conductive contact with the other device.

FIG. 1A is a schematic diagram of an example communication system 100 a.The example communication system 100 a includes mobile devices 102 a,102 b. The communication system 100 a can include additional ordifferent features and components. For example, the communication system100 a can include one or more networks, servers, computing systems,additional or different mobile devices, or any suitable combination ofthese other components. The components of the communication system 100 acan be configured as shown in FIG. 1A, or the communication system 100 acan be configured in another manner, as appropriate.

Generally, the mobile devices 102 a, 102 b can include any appropriatetypes of subsystems, modules, devices, components, and combinationsthereof. Examples of mobile devices include various types of mobiletelecommunication devices, smartphones, smartcards, identificationdevices, media players, headsets, personal digital assistants (PDAs),laptops, notebooks, tablets, etc. Example mobile devices are shown inFIG. 1B and FIG. 2. The example communication system 100 a can includeadditional or different types of devices, as appropriate. For example,in some implementations, another type of computing device can besubstituted for one or both of the mobile devices 102 a, 102 b.

The mobile devices 102 a and 102 b can be identical, similar, ordifferent types of devices. For example, the first mobile device 102 acan be a mobile telecommunication device, and the second mobile device102 b can be a tablet device or a laptop device. As another example, thefirst mobile device 102 a and the second mobile device 102 b can both bemobile telecommunication devices, or they can both be tablet devices.

The example mobile devices 102 a, 102 b shown in FIG. 1A each include auser interface 108, a processor 110, a memory 112 a or 112 b, and awireless interface 114. The mobile devices 102 a, 102 b can includeadditional or different features or components. The features andcomponents of the mobile devices 102 a, 102 b can be configured as shownand described with respect to FIG. 1A, or the features and components ofone or both of the mobile devices 102 a, 102 b can be configured in adifferent manner. In some implementations, the user interfaces 108, theprocessors 110, the memories 112 a, 112 b, the wireless interfaces 114,and possibly other components of the two mobile devices 102 a, 102 b canbe the same, or they can be different.

The user interface 108 can include any suitable user interface devicesor components. For example, the user interface 108 can include atouchscreen, a keyboard, a microphone, a pointing device (e.g., a mouse,a trackball, a stylus, etc.), or another type of user interface. Theuser interface 108 can detect a user interaction and generatecomputer-readable data or signals based on the user interaction. Forexample, the user interface may convert a user's keystrokes or otherinteractions to a voltage signal, and transmit the voltage signal to theprocessor 110, which can convert the voltage signals to binaryinformation for storage or further processing.

The processor 110 can include any suitable data processing apparatus.For example, one or more aspects of the processor 110 may be implementedby a microprocessor, a digital microcontroller, digital or analogcircuitry, or a combination of these and other types of data processinghardware or firmware. The processor 110 can include a main processor ofthe mobile device, and possibly one or more co-processors of the mobiledevice. In some implementations, the processor 110 includes a generalpurpose processor. Additionally or alternatively, the processor 110 caninclude one or more special purpose processors, such as, for example, acryptographic processor, a video compression processor, or another typeof special purpose processor. In some instances, one or more componentsof the processor 110 can be integrated or otherwise associated withanother component of the mobile device.

The processor 110 can execute instructions, for example, to generateoutput data based on data inputs. The instructions can include programs,codes, scripts or other types of data stored in memory. Additionally oralternatively, the instructions can be encoded as pre-programmed orre-programmable logic circuits, logic gates, or other types of hardwareor firmware components. In some instances, the processor 110 cangenerate output data by executing and/or interpreting software, scripts,programs, functions, executables, and/or other modules stored in thememory 112 a or 112 b. The processor 110 may perform one or more of theoperations shown in FIG. 3, 4A, 4B, or 4C. In some cases, the processorexecutes one or more operations of the messaging module 124.

The memories 112 a, 112 b can include any suitable computer-readablemedia. The memories 112 a, 112 b can include a volatile memory device, anon-volatile memory device, or both. The memories 112 a, 112 b caninclude one or more read-only memory devices, random-access memorydevices, buffer memory devices, or a combination of these and othertypes of memory devices. In some instances, one or more components ofthe memory can be integrated or otherwise associated with anothercomponent of the mobile device.

The memories 112 a, 112 b can store instructions (e.g., computer code)associated with an operating system, computer applications, and/or otherresources. The memories 112 a, 112 b can store application data and dataobjects that can be interpreted by one or more applications and/orvirtual machines running on the mobile device. The example memory 112 bof the mobile device 102 b includes a messaging module 124 and a sharedsecret 120; the example memory 112 a of the mobile device 102 a includesa messaging module 124, a shared secret 120, and a message 122. Thememories 112 a, 112 b can include additional or different types ofmodules and data, as appropriate.

The shared secret 120 can include any private information stored locallyon both of the mobile devices 102 a, 102 b. For example, the sharedsecret 120 can be a symmetric key or another type of private value thatis locally accessible on both mobile devices 102 a, 102 b. The sharedsecret 120 can include a single shared secret value or multiple sharedsecret values. The shared secret 120 can include any suitableinformation, which may be established between the mobile devices 102 a,102 b by any appropriate technique.

In some implementations, the shared secret 120 is established based onone or more of the techniques shown in FIG. 4A, 4B, or 4C, or by anothertechnique. For example, the shared secret 120 can be (or can be derivedfrom) a secret value entered by a user at both mobile devices 102 a, 102b. As another example, the shared secret 120 can be (or can be derivedfrom) a secret value transmitted to both devices over a private channel,or from one of the mobile devices 102 a, 102 b to the other device overa private channel. In some instances, the shared secret 120 can beestablished based on communication between the mobile devices 102 a, 102b over a public channel. For example, the shared secret 120 can beestablished based on a key agreement protocol, based on a pairingprotocol, or based on additional or different techniques.

The shared secret 120 can be stored on the first mobile device 102 awith additional information that associates the shared secret 120 withthe second mobile device 102 b. For example, the shared secret 120 canbe stored with (or in association with) information that identifies anaddress, component, or user of the second mobile device 102 b. As such,the first mobile device 102 a can access the shared secret 120 for usein communication with the second mobile device 102 b. Similarly, theshared secret 120 can be stored on the second mobile device 102 b withadditional information that associates the shared secret 120 with thefirst mobile device 102 a. Accordingly, the second mobile device 102 bmay access the shared secret 120 for use in communication with the firstmobile device 102 a. The mobile devices 102 a, 102 b may storeadditional shared secrets that are associated with additional ordifferent devices or entities.

The message 122 can include any type of information appropriate fortransmission by the wireless interface 114. For example, the message 122can include a link to content, information identifying or describingattributes of a user or a device, routing information for a contact(e.g., a phone number, an e-mail address, an IP address, etc.), or acombination of these and other types of information. In some instances,the message 122 can include content such as, for example, text data,image data, audio data, multimedia data, or a combination of these andother types of information.

The messaging module 124 can be implemented by hardware, software,firmware, or a combination thereof. For example, in some cases, all orpart of the messaging module 124 can be implemented as a softwareprogram executed by a microprocessor. As another example, in some cases,all or part of the messaging module 124 can be implemented in digital oranalog circuitry. In some instances, the messaging module 124 isintegrated with and/or utilizes other software or hardware resources ofthe mobile device, or the messaging module 124 can be a standalonemodule. In some implementations, some or all operations of the messagingmodule 124 can be executed by the processor 110 of the mobile device, bythe wireless interface 114 of the mobile device, or by any suitablecombination of these and other components of the mobile device.

In the example shown in FIG. 1A, the messaging module 124 can utilizethe shared secret 120 to provide trusted communications between themobile devices 102 a, 102 b. For example, the messaging module 124 ofthe first mobile device 102 a may utilize the shared secret 120 togenerate data 126 that can be used by the second mobile device 102 b toverify integrity of the message 122. The messaging module 124 can useany suitable functions, operations, or algorithms to generate the data126. In some implementations, the messaging module 124 may perform oneor more of the operations shown in FIG. 3, 4A, 4B, or 4C.

In some implementations, the messaging module 124 of the first mobiledevice 102 a can append the data 126 to the message 122 or otherwiseassociate the data 126 and the message 122 for transmission to thesecond mobile device 102 b. In some implementations, the messagingmodule 124 instructs the wireless interface 114 to wirelessly transmitthe message 122 and the data 126. The messaging module 124 of the secondmobile device 102 b can access the shared secret 120 and verifyintegrity of the message 122 based on the data 126 and the shared secret120. The messaging module 124 can use any suitable functions,operations, or algorithms to verify integrity of the message 122 basedon the data 126.

The data 126 can include any type of information that can be used toverify integrity of messages. For example, in some implementations, thedata 126 includes an authentication value. The authentication value caninclude information generated based on the message 122, the sharedsecret 120, and possibly other information. For example, because theauthentication value included in the data 126 is generated based on themessage 122 and the shared secret 120, the second mobile device 102 bcan verify the message 122 based on the authentication value and havesome assurance that the message 122 was sent from a trusted source.

In some implementations, the messaging module 124 of the first mobiledevice 102 a generates the authentication value included in the data126, and the data 126 is transmitted to the second mobile device 102 bwith the message 122. The messaging module 124 of the second mobiledevice 102 b can then generate a test authentication value forcomparison to the authentication value included in the data 126. In somecases, if the second mobile device 102 b determines that theauthentication values match, the second mobile device 102 b can acceptthe message; if the second mobile device 102 b determines that theauthentication values do not match, the second mobile device 102 b canreject the message.

In some implementations, the authentication value is a MessageAuthentication Code (MAC). For example, a MAC may be generated by akeyed Hash-based Message Authentication Code (HMAC) algorithm, oranother type of algorithm. In some cases, a MAC generated by an HMACalgorithm can be used to simultaneously verify integrity andauthenticity of the underlying message. Additional or different types ofauthentication values may be used. In some instances, the data 126includes a timestamp associated with the authentication value. Forexample, the timestamp may be used as a countermeasure against replayattacks. Accordingly, in some cases the data 126 includes anauthentication value and a timestamp value. The data 126 can includeadditional or different types of information.

The wireless interface 114 can include any suitable wireless interface.The wireless interface 114 may include, for example, a controller, atransceiver, and an antenna in any suitable configuration. The wirelessinterface 114 may include additional or different components. In someimplementations, the wireless interface 114 is a proximity-activatedwireless interface. For example, the wireless interface 114 can be anNFC interface or another type of proximity-activated wireless interface.Additional or different types of wireless interfaces,proximity-activated or otherwise, may be used. The wireless interface114 of the first mobile device 102 a can wirelessly communicate directlywith the wireless interface 114 of the second mobile device 102 b. Themobile devices 102 a, 102 b may include one or more additional wirelessinterfaces that communicate indirectly, for example, through a router, ahub, a relay, a gateway, or another type of intermediary component ordevice. As a specific example, in some implementations the mobiledevices 102 a, 102 b can communicate with each other indirectly over adata network or a telecommunications network.

The wireless interface 114 can detect proximity of another suitabledevice based on wireless interactions with the other device. Forexample, the wireless interface 114 may wirelessly transmit a pollingsignal or another type of interrogation message, and another device mayreceive the polling signal and transmit a response that can be detectedby the wireless interface 114. As such, the wireless interface 114 maydetect proximity of another device based on the other device's responseto a polling signal or another type of interrogation message. As anotherexample, the wireless interface 114 may wirelessly receive a pollingsignal or another type of interrogation message transmitted by anotherdevice. As such, the wireless interface 114 may detect proximity ofanother device based on a polling signal or other type of interrogationmessage transmitted by the other device. The wireless interface 114 maydetect proximity of another device based on additional or differenttechniques.

In the example communication system 100 a shown in FIG. 1A, the firstmobile device 102 a can detect proximity of the second mobile device 102b based on wireless interactions between the wireless interfaces 114.For example, if the first mobile device 102 a and the second device 102b are brought within a certain distance of each other, one or both ofthe wireless interfaces 114 may detect proximity of the other device. Insome implementations, the mobile devices 102 a, 102 b can detect eachother's proximity when the devices are brought within about 4 cm, 10 cm,or another distance of each other. In some instances, the conditionsunder which one of the mobile devices 102 a, 102 b detects proximity ofthe other may depend on settings or attributes of the particular mobiledevices. For example, the wireless interfaces 114 may detect proximitybased on receiving signals having a signal-to-noise ratio greater than athreshold level. Moreover, the conditions under which proximity can bedetected may depend on the physical orientations of the mobile devices102 a, 102 b, physical attributes of their environment, and otherconsiderations.

The wireless interface 114 of the first mobile device 102 a canwirelessly transmit the message 122 and the data 126 to the seconddevice 102 b. In some implementations, the first mobile device 102 awirelessly transmits the message 122 and the data 126 to the secondmobile device 102 b in response to detecting proximity of the secondmobile device 102 b. In some instances, the first mobile device 102 acan transmit information to the second mobile device 102 b based onadditional or different criteria. Moreover, the first mobile device 102a may perform additional or different operations in response todetecting proximity of the second mobile device 102 b.

In one aspect of operation, the first mobile device 102 a detectsproximity of the second mobile device 102 b based on an interactionbetween the wireless interfaces 114 of the mobile devices 102 a, 102 b.In response to detecting proximity of the second mobile device 102 b,the first mobile device 102 a can access the shared secret 120 and themessage 122. In some instances, the first mobile device 102 a generatesthe message 122 in response to detecting proximity of the second mobiledevice 102 b. The first mobile device 102 a generates the data 126 basedon the message 122 and the shared secret 120, and the first mobiledevice sends the data 126 and the message 122 to the second mobiledevice 102 b by a wireless interaction between the wireless interfaces114. In response to receiving the message 122 and the data 126, thesecond mobile device 102 b can access the shared secret 120 and use theshared secret 120 to verify integrity of the message 122. In cases wherethe second mobile device 102 b accepts the message 122, the secondmobile device 102 b can automatically take action based on the message122. For example, because the integrity of the message 122 has beenverified and accepted, the second mobile device 102 b can trust themessage 122 without requiring manual input, confirmation, oracknowledgement by a user.

FIG. 1B is a schematic diagram of an example communication system 100 b.The example communication system 100 b includes a mobiletelecommunication device 102 c and a tablet device 102 d. In someaspects, the communication system 100 b of FIG. 1B can represent anexample implementation of the communication system 100 a of FIG. 1A. Inthe example shown in FIG. 1B, the mobile telecommunication device 102 ccan be configured to operate as the mobile device 102 a of FIG. 1A, andthe tablet device 102 d can be configured to operate as the mobiledevice 102 b of FIG. 1B. The communication system 100 b can includeadditional or different features not shown in FIG. 1B. For example, thecommunication system 100 b can include a data network (e.g., an ad-hocnetwork, a WiFi network, a local area network, etc.) that allows themobile telecommunication device 102 c and the tablet device 102 d tocommunicate with each other, and possibly with other devices or systems.

In the example shown in FIG. 1B, the mobile telecommunication device 102c and the tablet device 102 d are both NFC-enabled devices. As such,both devices include an NFC module, and the devices can wirelesslycommunicate with each other by interactions between their NFC modules.In addition, a shared secret has been established on the mobiletelecommunication device 102 c and the tablet device 102 d.

As shown in FIG. 1B, the mobile telecommunication device 102 c displaysa link 150 on a display of the mobile telecommunication device 102 c.The link 150 can be a link to content accessible by the Internet, a linkto content accessible on a local area network, a link to content storedlocally on the tablet device 102 d, or another type of link. The examplelink 150 shown in FIG. 1B is a link to a web page.

In some instances, if the mobile telecommunication device 102 c isbrought in proximity of the tablet device 102 d while the link 150 isdisplayed on the mobile telecommunication device 102 c, the mobiletelecommunication device 102 c automatically sends the link 150 to thetablet device 102 d by NFC, and the link 150 is automatically opened,and the corresponding content is automatically displayed on the tabletdevice 102 d. For example, the mobile telecommunication device 102 c maydetect proximity of the tablet device 102 d based on an interactionbetween the NFC modules of the two devices. In response to detectingproximity of the tablet device 102 d, the mobile telecommunicationdevice 102 c can generate a message 152 that identifies the link 150,generate integrity data 154 based on the message 152 and the sharedsecret, and then wirelessly transmit the message 152 and the integritydata 154 directly to the tablet device 102 d.

The message 152 and the integrity data 154 can be transmitted from themobile telecommunication device 102 c to the tablet device 102 d by awireless interaction between the NFC modules of the two devices. In someimplementations, the tablet device 102 d receives the message 152 andthe integrity data 154 and then verifies the integrity of the message152 based on the integrity data 154 and the shared secret. For example,the tablet device 102 d can locally generate integrity data and comparethe locally-generated integrity data to the integrity data 154 receivedwith the message 152. If the tablet device 102 d accepts the message,the tablet device 102 d can automatically access the content at the link150 and display the content on the display of the tablet device 102 d.As shown in FIG. 1B, the tablet device 102 d opens the link 150 using aweb browser application 160, and the corresponding content can bedisplayed in the web browser window 162.

Because the integrity of the message 152 is verified based on the sharedsecret, the tablet device 102 d can trust the message 152, for example,without prompting for acknowledgment by a user. Similarly, in someimplementations, the tablet device 102 d can reject the message 152without prompting for user interaction. For example, if the tabletdevice 102 d determines that the integrity data 154 does not match thelocally-generated integrity data, the tablet device 102 d can reject themessage 152. In some instances, the tablet device 102 d may beconfigured to prompt for user acknowledgment after the message isaccepted or rejected based on the integrity data 154.

FIG. 2 is a schematic diagram of an example mobile telecommunicationdevice 200. For example, the mobile telecommunication device 200 can bea BLACKBERRY® telecommunication device and/or another type of mobiletelecommunication device. In some implementations, the mobiletelecommunication device 200 is a dual-mode device. The example mobiletelecommunication device 200 in FIG. 2 includes a microprocessor 202, acommunication subsystem 204, random access memory (RAM) 206,non-volatile memory 208, a display 210, one or more auxiliaryinput/output (I/O) devices 212, a data port 214, a keyboard 216, aspeaker 218, a microphone 220, a Bluetooth subsystem 222, a Near FieldCommunication (NFC) subsystem 223, other device subsystems 224, aSIM/RUIM card (i.e., a Subscriber Identity Module or a Removable UserIdentity Module) 226, a SIM/RUIM interface 228, a rechargeable battery230, a battery interface 232, and possibly other components. The mobiletelecommunication device 200 can include the same, additional, ordifferent features, which may be arranged or configured to operate inthe manner shown or in a different manner.

The example mobile telecommunication device 200 is a battery-powereddevice that includes a battery interface 232 that receives directcurrent electrical power from one or more rechargeable batteries 230.The battery 230 can be a smart battery with an embedded microprocessoror a different type of battery. The battery interface 232 may be coupledto a regulator (not shown), which may assist the battery 230 inproviding power V+ to the mobile telecommunication device 200.Additionally or alternatively, the mobile telecommunication device 200may receive power from an external source (e.g., an alternating currentpower source, an adapter, a converter, etc.) and/or a different type ofinternal power source.

The example mobile telecommunication device 200 shown in FIG. 2 canoperate as a two-way communication device having voice and datacommunication capabilities. The mobile telecommunication device 200 maycommunicate over wireless networks, including wireless telecommunicationnetworks, wireless data networks, combined voice and data networks,and/or other types of wireless networks. Thus, the mobiletelecommunication device 200 may communicate over a voice network, suchas any of the analog or digital cellular networks, and may alsocommunicate over a data network. Voice and data networks may beimplemented as separate communication networks using separateinfrastructure, such as base stations, network controllers, etc., or thevoice and data networks may be integrated into a single wirelessnetwork. The networks can include one or more local, regional, national,or global networks. The networks can include one or more cellularnetworks. In some implementations, wireless networks utilize one or morecommunication protocol standards, for example, 3G, 4G, GSM, CDMA, GPRS,EDGE, LTE or others.

In the example mobile telecommunication device 200 shown in FIG. 2, thecommunication subsystem 204 includes a receiver 250, a transmitter 252,antennae 254 and 256, one or more local oscillators 258, a digitalsignal processor (DSP) 260 and possibly other features. The antennae 254and 256 may include antenna elements of a multiple-element antenna,embedded antennae, radio frequency (RF) antennae, and/or other types ofantennae. The communication subsystem 204 can be used to communicatewith a network. The DSP 260 can be used to receive and send signalsthrough the receiver 250 and the transmitter 252, respectively, and theDSP 260 can provide control information to the receiver 250 and thetransmitter 252. For example, the gain levels applied to communicationsignals in the receiver 250 and the transmitter 252 can be adaptivelycontrolled through automatic gain control algorithms implemented in theDSP 260. Additional and/or different types of control algorithms may beimplemented in the DSP 260 to provide more sophisticated control of thecommunication subsystem 204.

In some implementations, the local oscillator 258 includes a singlelocal oscillator that provides a reference signal for the receiver 250and the transmitter 252, for example, where voice and datacommunications occur at a single frequency, or closely-spaced sets offrequencies. In some cases, for example if different frequencies areutilized for voice communications and data communications, the localoscillator 258 may include multiple local oscillators that are used togenerate multiple different frequencies corresponding to the voice anddata networks. Information, which may include both digital voice anddigital data information, can be communicated within the mobiletelecommunication device 200 to and from the communication subsystem 204through a link or bus between the DSP 260 and the microprocessor 202.The design and configuration of the communication subsystem 204, such asfrequency band, component selection, power level, etc., may depend onthe communication network in which the mobile telecommunication device200 is intended to operate. For example the communication subsystem 204may be configured for 2G, 2.5G, 3G, 4G, and other voice and datanetworks, such as GSM, CDMA2000, GPRS, EDGE, W-CDMA (UMTS), FOMA, EV-DO,TD-SCDMA, HSPA, HSOPA, and the like.

After any required network registration or activation procedures havebeen completed, the mobile telecommunication device 200 may send andreceive communication signals, including both voice and data signals,over the wireless networks. Signals received by the antenna 254 from thecommunication network can be routed to the receiver 250, which canprovide signal amplification, frequency down conversion, filtering,channel selection, etc., and may also provide analog to digital signalconversion. Analog to digital conversion of the received signal mayallow the resulting digital signal to be decoded by the DSP 260. Signalsto be transmitted to the network can be processed (e.g., modulated,encoded, etc.) by the DSP 260 and then provided to the transmitter 252for digital to analog conversion, frequency up conversion, filtering,amplification and transmission to the communication network via theantenna 256.

In some implementations, the mobile telecommunication device 200 cansend and receive communication signals over the wireless network afterwireless network registration or activation procedures have beencompleted. The wireless network registration or activation proceduresfor the mobile telecommunication device 200 may vary based on the typeof network or networks with which the mobile telecommunication device200 operates. Wireless network access for the example mobiletelecommunication device 200 shown in FIG. 2 can be associated with asubscriber or user of the mobile telecommunication device 200. Inparticular, the SIM/RUIM card 226 in the SIM/RUIM interface 228 mayidentify the subscriber or user of the mobile telecommunication device200. The SIM/RUIM card 226 in the SIM/RUIM interface 228 may enableaccess to subscribed services through the wireless network. For example,subscribed services may include web browsing, e-mail, voice mail, ShortMessage Service (SMS), Multimedia Messaging Services (MMS), and/orothers. The SIM/RUIM card 226 in the SIM/RUIM interface 228 cancommunicate with the microprocessor 202 on the mobile telecommunicationdevice 200. To identify the subscriber, the SIM/RUIM card 226 mayinclude user parameters, such as an International Mobile SubscriberIdentity (IMSI) and/or another type of subscriber identifier. TheSIM/RUIM card 226 may store additional and/or different subscriberinformation, including calendar information, call log information,contacts information, and/or other types of information. Additionally oralternatively, user identification information can also be stored in thenon-volatile memory 208.

The data port 214 may include a serial port, a parallel port, and/oranother type of connection port. In some implementations, the data port214 is a Universal Serial Bus (USB) port that includes data lines fordata transfer and a supply line that can provide a charging current tocharge the battery 230 of the mobile telecommunication device 200. Themobile telecommunication device 200 may be manually synchronized with ahost system, for example, by connecting the mobile telecommunicationdevice 200 through the data port 214 (e.g., in an interface cradleand/or another type of wired connection) that couples the mobiletelecommunication device 200 to a data port of a computer system orother device. The data port 214 may also be used to enable a user to setpreferences through an external device or software application, or todownload other programs for installation. The wired connection of thedata port 214 may be used to load an encryption key onto the device.

The Bluetooth subsystem 222 and the NFC subsystem 223 each provide forcommunication between the mobile telecommunication device 200 anddifferent systems or devices, without the use of the wireless network.For example, Bluetooth subsystem 222 and the NFC subsystem 223 caninclude radio frequency devices and associated circuits and componentsfor short-range communication. The mobile telecommunication device 200can include additional or different types of short-range communicationsubsystems. For example, the mobile telecommunication device 200 caninclude an infrared communication subsystem, a WiFi communicationsubsystem, or another type of short-range communication subsystem. Insome implementations, one or more of the short-range communicationsubsystems can be configured according to one or more standards or othertypes of specifications. Examples of short-range communication standardsinclude standards developed by the Infrared Data Association (IrDA),BLUETOOTH®, the 802.11 family of standards developed by IEEE, the NFCForum, and others.

The Bluetooth subsystem 222 can include, for example, a controllermodule, a transceiver module, an antenna, or any suitable combination ofthese and other components. The Bluetooth subsystem 222 can beconfigured to send and receive messages according to any appropriatestandard or specification for Bluetooth devices. In someimplementations, the Bluetooth subsystem 222 can be configured tocommunicate by wireless signals having one or more frequencies in arange of 2400 MHz to 2480 MHz, or in another frequency range. TheBluetooth subsystem 222 can be configured to communicate with otherBluetooth-enabled devices.

The NFC subsystem 223 can include, for example, a controller module, atransceiver module, an antenna, or any suitable combination of these andother components. The NFC subsystem 223 can be configured to send andreceive messages according to any appropriate standard or specificationfor NFC devices. In some implementations, the NFC subsystem 223 can beconfigured to communicate by wireless signals having one or morefrequencies at or near 13.56 MHz, or in another frequency range. The NFCsubsystem 223 can be configured to detect proximity of NFC tags andother NFC-enabled devices. The NFC subsystem 223 can be configured tocommunicate with the NFC tags and other NFC-enabled devices, forexample, in response to detecting their proximity or in response toother events or criteria.

The example microprocessor 202 can manage and control the overalloperation of the mobile telecommunication device 200. Many types ofmicroprocessors or microcontrollers may be used, as appropriate.Additionally or alternatively, a single DSP 260 may be used to carry outone or more functions of the microprocessor 202. Low-level communicationfunctions, including data and voice communications, may be performedthrough the DSP 260 in the communication subsystem 204. High-levelcommunication applications, such as voice communication applications,data communication applications, and/or other types of softwareapplications may be stored in the non-volatile memory 208 for executionby the microprocessor 202. The microprocessor 202 can interact withother device subsystems, such as the display 210, the RAM 206, theauxiliary input/output (I/O) devices 212, the data port 214, thekeyboard 216, the speaker 218, the microphone 220, the SIM/RUIMinterface 228, the battery interface 232, the Bluetooth subsystem 222,the NFC subsystem 223, and any other device subsystems generallydesignated as 224.

The non-volatile memory 208 includes erasable persistent storage, forexample, flash memory, battery-backed-up RAM, and/or other types ofmemory. In the example shown in FIG. 2, the non-volatile memory 208stores instructions and data associated with an operating system 234,programs 236 that provide various types of functionality for the mobiletelecommunication device 200, and other types of information. Thenon-volatile memory 208 may include a file system to facilitate storageof data items on the device. For example, the operating system 234, theprograms 236, and/or other modules executed on the microprocessor 202may store, retrieve, modify, delete, and/or otherwise manipulate data byaccessing (e.g., read, write, etc.) the file system provided on thenon-volatile memory 208.

Data stored in the non-volatile memory 208 and/or othercomputer-readable media on the mobile telecommunication device 200 mayinclude user application data, text files, image files, voicemail data,and other data generated by the user at the mobile telecommunicationdevice 200 or received and stored by the mobile telecommunication device200. The user application data may include, for example, e-mail messagedata, address book data, contact information data, calendar appointmentdata, instant message data, SMS message data, voicemail data,user-entered data, and/or other types of application data. Voicemaildata may include digitized audio recordings and/or stub entriesavailable for viewing in a messaging application indicating theavailability of a voicemail message stored at another location.User-entered data may include text-based, graphic, or other multimediafiles loaded onto the mobile telecommunication device 200 by the user.

The operating system 234 can control low-level functions of the mobiletelecommunication device 200 and facilitate operation of the programs236. For example, the operating system 234 may provide an interfacebetween one or more of the programs 236 and one or more hardwarecomponents on the mobile telecommunication device 200. The programs 236include computer program modules that can be executed by themicroprocessor 202 (and/or the DSP 260 in some instances). In someimplementations, one or more of the programs 236 are executed by themicroprocessor 202 and provide a high-level interface between a user andthe mobile telecommunication device 200. The user interface provided bya program 236 typically includes a graphical component provided throughthe display 210, and may additionally include an input/output componentprovided through the auxiliary I/O devices 212, the keyboard 216, thespeaker 218, and/or the microphone 220. The operating system 234,specific device applications or programs 236, or parts thereof, may betemporarily loaded into a volatile store, such as RAM 206, for fasteroperation. Moreover, received communication signals may also betemporarily stored to RAM 206 before they are permanently written to afile system in the non-volatile memory 208.

The programs 236 stored in the non-volatile memory 208 may include, forexample, a message application, a calendar application, one or morethird party applications, and other types of applications. The programs236 may include additional or different modules, programs, orapplications, such as, for example, a Personal Information Manager (PIM)module, a connect module, a device state module, an IT policy module, amulti service platform manager, and/or others. The programs 236 mayinclude programs that control basic device operations, which may beinstalled on the mobile telecommunication device 200 during itsmanufacture and/or initial configuration. Other types of softwareapplications, such as, for example, third party applications and/orother types of modules, may be added after the manufacture and initialconfiguration of the mobile telecommunication device 200. Examples ofthird party applications include games, utilities, internetapplications, etc. Generally, any of the programs 236 may be updatedand/or modified at any time. The additional applications and/or updatesto applications can be loaded onto the mobile telecommunication device200 through the wireless network, the auxiliary I/O devices 212, thedata port 214, the Bluetooth subsystem 222, the NFC subsystem 223, orany other suitable device subsystem 224. The non-volatile memory 208 mayalso store keys, which may include encryption and decryption keys andaddressing information for use in communicating between the mobiletelecommunication device 200 and servers.

FIG. 3 is a signaling and flow diagram showing an example process 300for communication among mobile devices. The process 300 can beimplemented in a communication system. For example, the process 300 canbe implemented by one or more components of the communication system 100a shown in FIG. 1A, the communication system 100 b shown in FIG. 1B, orby a different type of system. The example process 300 shown in FIG. 3can be modified or reconfigured to include additional, fewer, ordifferent operations, which can be performed in the order shown or in adifferent order. In some instances, one or more of the operations can berepeated or iterated, for example, until a terminating condition isreached. In some implementations, one or more of the individualoperations shown in FIG. 3A can be executed as multiple separateoperations, or one or more subsets of the operations shown in FIG. 3Acan be combined and executed as a single operation.

A first device 302 a and a second device 302 b are shown in FIG. 3. Thedevices 302 a, 302 b may include mobile devices, computing systems, orany suitable combination of these and other types of devices. Forexample, the devices 302 a, 302 b can be the mobile devices 102 a, 102 bof FIG. 1A, the mobile devices 102 c, 102 d of FIG. 1B, or any otherpair of suitable devices. In some implementations, the first device 302a or the second device 302 can be a mobile telecommunication device, aspeakerphone device, a tablet device, a headset device, or any othersuitable type of device. In the discussion that follows, operationsshown in FIG. 3 are described as being performed by the first device 302a, the second device 302 b, or both. In some implementations, one ormore individual operations shown in FIG. 3 can be performed by one ormore additional or different devices, or one or more of the operationsthat are shown as being performed by a combination of devices can beperformed by a single device. As such, the example process 300 can bemodified or reconfigured, as appropriate, for various types ofimplementations and in multiple different contexts.

At 310, a shared secret is established between the devices 302 a, 302 b.The shared secret can be a secret value (e.g., a private key) that isaccessible to both devices 302 a, 302 b but not generally accessible byuntrusted entities. The shared secret can be established in any suitablemanner. In some implementations, the shared secret is established in amanner that is secure against eavesdropping or more sophisticatedattacks by a third party adversary. Generally, a shared secret can beestablished between any two or more devices. For example, a particularuser could have a shared secret established among the user's phone,laptop, tablet, and potentially other devices controlled by the user. Asanother example, two users could established a shared secret betweentheir respective devices.

In some instances, the shared secret can be established by one or moreof the example techniques shown in FIG. 4A, 4B, or 4C or by anothertechnique. For example, in some implementations, the shared secret isestablished based on credentials exchanged between the first device 302a and the second device 302 b over one or more wireless interfaces(e.g., NFC, Bluetooth, WiFi, etc.). As another example, in someimplementations, the shared secret is established based on credentialsprovided through a user interface of the first device 302 a, credentialsprovided through a user interface of the second device 302 b, or both.As another example, in some implementations, the shared secret isestablished based on one or more certificates provided by a certificateauthority.

At 312, the first device 302 a detects proximity of the second device302 b. The first device 302 a may detect proximity of the second device302 b based on physical proximity of the two devices and possibly othercriteria. For example, the first device 302 a may detect proximity ofthe second device 302 b based on the second device 302 b moving within adetection range (e.g., 4 cm, 10 cm, 20 cm, etc.) of the first device 302a. In some cases, the first device 302 a detects proximity of the seconddevice 302 b based on a direct wireless interaction between the devices.In some implementations, the first device 302 a detects proximity of thesecond device 302 b by a proximity-activated wireless interface of thefirst mobile device. For example, the proximity-activated wirelessinterface can be an NFC interface, or another type of interface. In someimplementations, the first device 302 a detects proximity of the seconddevice 302 b based on information transmitted wirelessly from the seconddevice 302 b directly to the first device 302 a.

In some implementations, at 312 the second device 302 b wirelesslytransmits information that permits the first device 302 a to detectproximity of the second device 302 b. For example, in someimplementations, the second device 302 b transmits a polling signalwithin range of the first device 302 a, and the first device 302 adetects proximity of the second device 302 b by receiving the pollingsignal. As another example, in some implementations, the second device302 b receives a polling signal from the first device 302 a, the seconddevice 302 b transmits a response to the polling signal within range ofthe first device 302 a, and the first device 302 a detects proximity ofthe second device 302 b by receiving the response. The second device 302b may transmit additional or different types of information to permitthe first device 302 a to detect proximity of the second device 302 b.

At 314, the first device 302 a accesses a message. The message caninclude any type of information generated by the first device 302 a, anytype of information received by the first device 302 a from anothersource, or a combination. In some cases, the message is accessed by thefirst device 302 a in response to detecting proximity of the seconddevice 302 b. For example, the first device 302 a may generateinformation, instructions, or other types of data to be sent to thesecond device 302 b.

In some cases, the message can include a link to content, routinginformation for an e-mail or a call, or other types of information. Asan example, if the first device 302 a detects proximity of the seconddevice 302 b while a link is displayed or highlighted in a graphicaldisplay of the first device 302 a, the first device 302 a may generate amessage that conveys the link to the second device 302 b so that thelink can be opened on the second device 302 b. As another example, ifthe first device 302 a detects proximity of the second device 302 bwhile a phone number or information associated with a phone number(e.g., the name of a contact) is displayed or highlighted in a graphicaldisplay of the first device 302 a, the first device 302 a may generate amessage that conveys the phone number to the second device 302 b so thatthe second device 302 b can initiate a call to the phone number.Additional or different types of routing information may be utilized, asappropriate.

At 316, the first device 302 a accesses the shared secret. In somecases, the shared secret is accessed by the first device 302 a inresponse to detecting proximity of the second device 302 b. In someimplementations, the shared secret stored at the first device 302 a isassociated with the second device 302 b. For example, the shared secretmay be stored at the first device 302 a with information indicating thatthe shared secret was established with the second device 302 b. As such,if the first device 302 a identifies that a message is to be sent to thesecond device 302 b, the first device 302 a can retrieve a shared secretvalue associated with the second device 302 b. In some cases, the firstdevice 302 a can then use the shared secret value associated with thesecond device 302 b to generate integrity data for the message, whichcan enable the second device 302 b to trust the message withoutacknowledgement from a user.

At 318, the first device 302 a generates integrity data. In someinstances, the integrity data are generated based on the message, theshared secret, and possibly additional information. The integrity datacan include information that allows the second device 302 b to verifyintegrity of the message. In some implementations, generating theintegrity data includes generating an authentication value, a timestampvalue, or a combination of these and other types of integrity data. Forexample, in some cases an authentication value is generated byevaluating a keyed hashing algorithm based on the message and the sharedsecret value. As such, the authentication value can be a MessageAuthentication Code (MAC) generated by evaluating a keyed Hash-basedMessage Authentication Code (HMAC) algorithm based on the message andthe shared secret. In some cases, the first device 302 a can generate atimestamp value associated with the authentication value. For example,the timestamp value can be used to prevent or reduce the likelihood of areplay attack. In some instances, the first device 302 a appends theauthentication value, the timestamp, or both to the message.

At 320, the first device 302 a wirelessly transmits the message and theintegrity data to the second device 302 b. For example, the first device302 a can wirelessly transmit the authentication value, the timestampvalue, or both values directly to the second device 302 b. In someinstances, the message and the integrity data are transmitted to thesecond device 302 b in response to detecting proximity of the seconddevice 302 b. In some implementations, the message and theauthentication value are wirelessly transmitted by theproximity-activated wireless interface of the first device 302 a. Inother words, the wireless interface that detected proximity of thesecond device 302 b (at 312) can also be used to transmit the messageand the integrity data to the second device 302 b (at 320). In someimplementations, the message and the integrity data are transmitted byan NFC module of the first device 302 a and received by an NFC module ofthe second device 302 b.

At 322, the second device 302 b wirelessly receives the message and theintegrity data from the first device 302 a. In some instances, themessage and authentication value are received at the second device 302 bdirectly from the first device 302 a in response to the second device302 b transmitting information that permits the first device 302 a todetect proximity of the second device 302 b. In some implementations,the message and the authentication value are wirelessly received by aproximity-activated wireless interface of the second device 302 b (e.g.,an NFC interface or another type of interface). In other words, thewireless interface that sent information to the first device 302 a thatallowed the first device 302 a to detect proximity of the second device302 b (at 312) can also be used to receive the message and the integritydata from the first device 302 a (at 322).

At 324, the second device 302 b accesses the shared secret. In somecases, the shared secret is accessed by the second device 302 b inresponse to detecting proximity of the first device 302 a, in responseto identifying that the message was transmitted by the first device 302a, or both. In some implementations, the shared secret is associatedwith the first device 302 a. For example, the shared secret may bestored at the second device 302 b with information indicating that theshared secret was established with the first device 302 a. As such, ifthe second device 302 b identifies that a message was received from thefirst device 302 a, the second device 302 b can retrieve a shared secretvalue associated with the first device 302 a. In some cases, the seconddevice 302 b can then use the shared secret value associated with thefirst device 302 a to verify integrity of the message. As such, if theintegrity of the message is verified by the second device 302 b based onthe shared secret, the message can be trusted by the second device 302 bwithout acknowledgement from a user.

At 326, the second device 302 b verifies integrity of the message. Forexample, when the integrity data includes an authentication value, theintegrity of the message can be verified based on the authenticationvalue. In some instances, a test authentication value is generatedlocally at the second device 302 b based on the message and the sharedsecret, and the integrity of the message is verified by comparing thetest authentication value with the authentication value received fromthe first device 302 a. The test authentication value can be generatedby the second device 302 b using the same technique used by the firstdevice 302 a to generate the authentication value. For example, whenappropriate, the authentication value can be generated by evaluating akeyed hashing algorithm based on the message and the shared secretvalue. As such, the test authentication value can be a MessageAuthentication Code (MAC) generated by evaluating a keyed Hash-basedMessage Authentication Code (HMAC) algorithm based on the message andthe shared secret.

In some cases, the integrity of the message can be verified bydetermining whether the first authentication value matches the secondauthentication value. For example, the message can be accepted by thesecond device 302 b if the second device 302 b determines that the testauthentication value matches the authentication value received from thefirst device 302 a; the message can be rejected by the second device 302b if the second device 302 b determines that the test authenticationvalue does not match the authentication value received from the firstdevice 302 a. In some cases, the integrity of the message can be furtherverified based on a timestamp associated with the authentication valuereceived from the first device 302 a.

The second device may perform one or more additional operations inresponse to verifying the integrity of the message. For example, whenthe message includes a link to content, the second device 302 b canautomatically display the content in response to verifying the integrityof the message. In some cases, the second device 302 b accesses anddisplays the content independent of user confirmation or useracknowledgement at the second device 302 b. As another example, when themessage includes a phone number, the second device 302 b canautomatically call the phone number in response to verifying theintegrity of the message. In some cases, the second device 302 binitiates a call independent of user confirmation or useracknowledgement at the second device 302 b.

FIGS. 4A-4C are signaling and flow diagrams showing three exampleprocesses 400 a, 400 b, 400 c for establishing a shared secret amongmobile devices. The processes 400 a, 400 b, 400 c can be implemented ina communication system. For example, the processes 400 a, 400 b, 400 ccan be implemented by one or more components of the communication system100 a shown in FIG. 1A, the communication system 100 b shown in FIG. 1B,or by a different type of system. The example processes 400 a, 400 b,400 c can be modified or reconfigured to include additional, fewer, ordifferent operations, which can be performed in the order shown or in adifferent order. In some instances, one or more of the operations can berepeated or iterated, for example, until a terminating condition isreached. In some implementations, one or more of the individualoperations shown in FIG. 4A, 4B, or 4C can be executed as multipleseparate operations, or one or more subsets of the operations can becombined and executed as a single operation.

Each of the example processes 400 a, 400 b, and 400 c are illustrated asbeing performed by a first device 402 a and a second device 402 b. Thedevices 402 a and 402 b may include mobile devices, computing systems,or any suitable combination of these and other types of devices. Forexample, the devices 402 a, 402 b can be the mobile devices 102 a, 102 bof FIG. 1A, the mobile devices 102 c, 102 d of FIG. 1B, the devices 302a, 302 b of FIG. 3, or any other pair of suitable devices. In thediscussion that follows, operations shown in FIGS. 4A, 4B, and 4C aredescribed as being performed by the first device 402 a, the seconddevice 402 b, or both. In some implementations, one or more individualoperations shown in FIGS. 4A, 4B, and 4C can be performed by one or moreadditional or different devices, and one or more of the operations thatare shown as being performed by a combination of devices can beperformed by a single device. As such, the example processes 400 a, 400b, 400 c can be modified or reconfigured, as appropriate, for varioustypes of implementations and in multiple different contexts.

FIG. 4A shows the example process 400 a for establishing a shared secretbetween the devices 402 a and 402 b. In the example process 400 a shownin FIG. 4A, the devices 402 a and 402 b each include two or morewireless interfaces. In particular, both devices include an NFCinterface and another wireless interface (e.g., Bluetooth, WiFi, etc.).In some implementations, the two wireless interfaces of each device areconfigured to transmit wireless signals in different frequency ranges.In some cases, the NFC interfaces 404 a, 404 b can be configured totransmit wireless signals at a frequency at or near 13.56 MHz, and theother interfaces 406 a, 406 b can be configured to transmit wirelesssignals at another frequency. For example, the other interfaces 406 a,406 b may be configured to transmit wireless signals at frequencies in arange of 2400 MHz to 2480 MHz (e.g., for Bluetooth), at frequenciesgreater than 1 GHz (e.g., for WiFi), or at another frequency. Thedevices 402 a, 402 b may include additional or different features orcomponents, as appropriate.

At 410, the NFC interface 404 a of the first device 402 a sends ahandover request to the NFC interface 404 b of the second device 402 b.The handover request sent by NFC can include a request to communicateover an alternative carrier. The handover request can include anidentification of available alternative carriers, such as, for example,Bluetooth, WiFi, or another type of carrier. At 412, the NFC interface404 b of the second device 402 b sends a handover selection to the NFCinterface 404 a of the first device 402 a. The handover selection canidentify an alternative carrier selected by the second device 402 b. Forexample, the handover selection can identify that the second device 402b has agreed to communicate by Bluetooth, by WiFi, or by anotheralternative carrier.

In some implementations, one or more aspects of the handover request (at410) and the handover selection (at 412) can be executed based onconventional techniques. Some example conventional techniques forgenerating a handover request and a handover selection are described inthe Connection Handover Technical Specification published by the NFCForum (see, e.g., Connection Handover 1.2, dated Jul. 7, 2010). Thehandover request (at 410) and the handover selection (at 412) can beexecuted based on additional or different techniques.

At 414 a and 414 b, the first device 402 a and the second device 402 bexchange credentials. In particular, at 414 a, the NFC interface 404 aof the first device 402 a and the NFC interface 404 b of the seconddevice 402 b exchange a first set of credentials; and at 414 b, theother interface 406 a of the first device 402 a and the other interface406 b of the second device 402 b exchange a second set of credentials.As such, in the example shown in FIG. 4A, credentials are split intomultiple parts, and a security association is established over multiplewireless interfaces. In some instances, transmitting different parts ofthe access credentials by different wireless interfaces can reduce thelikelihood of an eavesdropper acquiring the full credentials, forexample, at a single point of attack. The credentials exchanged at 414 aand 414 b can be used by the devices 402 a, 402 b to derive a sharedsecret.

Some wireless connections, such as Bluetooth, WiFi, and others, utilizea pairing protocol with some level of security to protect againsteavesdropping. When two devices execute the paring protocol, a sharedsecret can be established between the devices. Accordingly, a sharedsecret can be established between the devices 402 a, 402 b based atleast partially on a Bluetooth, WiFi, or another type pairing protocol.In some implementations, a different shared secret can be establishedeach time the devices are paired.

As shown in FIG. 4A, the pairing between the devices can be leveragedfor future NFC communication. For example, in some implementations, thedevices 402 a, 402 b can use the shared secret established based on thepairing protocol to verify integrity of messages exchanged between thedevices 402 a, 402 b over NFC. Accordingly, in the example shown in FIG.4A, a shared secret is established between the devices 402 a, 402 bbased on interactions between the other interfaces 406 a, 406 b (e.g.,Bluetooth or WiFi), and the shared secret is used to exchange trustedmessages between the NFC interfaces 404 a, 404 b.

At 416, the NFC interface 404 a of the first device 402 a and the NFCinterface 404 b of the second device 402 b exchange messages andintegrity data. Having established the shared secret, the devices 402 a,402 b can generate integrity data for messages to be exchanged over NFC.The integrity data can include, for example, an authentication valuebased on the shared secret. The integrity data can additionally includea timestamp value, for example, indicating when the authentication valuewas generated, or another relevant time. In some implementations, thedevices 402 a, 402 b shown in FIG. 4A can communicate based on one ormore operations of the example process 300 shown in FIG. 3. The devices402 a, 402 b may communicate based on additional or differenttechniques.

In some examples, when the first device 402 a has a message to send tothe second device, the first device 402 a generates an authenticationvalue based on the message and the shared secret, the first device 402 agenerates a timestamp value associated with the authentication value,and the first device 402 a sends the message along with theauthentication value and the timestamp value to the second device 402 b.In some instances, the authentication value, the timestamp value, orboth can be appended to the message. In some instances, theauthentication value and the timestamp value can be associated with themessage in a different manner.

The second device 402 b can verify the integrity of the message, andthereby determine whether to trust the message based on theauthentication value and the timestamp value. For example, the seconddevice 402 b can check that the timestamp is within a certain tolerance,for example, to prevent replay attacks. The second device 402 b cancheck that the authentication value was generated based on the messageand the shared secret. The second device 402 b may verify the integrityof the message using additional or different techniques, as appropriate.

The devices 402 a, 402 b can exchange multiple NFC messages based on asingle shared secret. In some instances, the devices 402 a, 402 b canrefresh the shared secret after a specified amount of time or based onother criteria. For example, the shared secret can be considered validfor a certain period of time or a certain number of messages, and then anew shared secret can be established between the devices 402 a, 402 b byany suitable technique.

FIG. 4B shows the example process 400 b for establishing a shared secretbetween the devices 402 a and 402 b. In the example process 400 b shownin FIG. 4B, the devices 402 a and 402 b each include an NFC interfaceand a user interface, and the user interface of each device is operableto receive input from a user 409. The example user interfaces 408 a, 408b can include any suitable user interface components or modules. Forexample, a user interface can include a touchscreen, a keyboard, atrackball, a pointing device, or any suitable combination of these andother types of user interface devices. The devices 402 a, 402 b mayinclude additional or different features or components, as appropriate.

At 420 a and 420 b, the devices 402 a, 402 b receive credentials. At 420a, the user interface 408 a of the first device 402 a receivescredentials from the user 409; and at 420 b, the user interface 408 b ofthe second device 402 b receives credentials from the user 409. In someexamples, the credentials are received at the respective devices fromthe same user or from two different users. The credentials provided bythe user 409 can include, for example, alphanumeric symbols enteredthrough a keyboard or a graphical interface, gestures or movementsdetected by a pointing device, or a combination of these and other typesof information. Each of the devices 402 a, 402 b can use the credentialsprovided by the user 409 as a shared secret, or each of the devices 402a, 402 b can derive or otherwise generate a shared secret based on thecredentials provided by the user 409.

At 422, the NFC interface 404 a of the first device 402 a and the NFCinterface 404 b of the second device 402 b can exchange messages andintegrity data. In some implementations, the devices 402 a, 402 b canexchange messages and integrity data as described with respect tooperation 416 shown in FIG. 4A. For example, having established a sharedsecret based on the credentials entered by the user 409, the devices 402a, 402 b can generate integrity data for messages to be exchanged overNFC. The integrity data can include, for example, an authenticationvalue based on the shared secret. The integrity data can additionallyinclude a timestamp value, for example, indicating when theauthentication value was generated, or another relevant time. In someimplementations, the devices 402 a, 402 b shown in FIG. 4B cancommunicate based on one or more operations of the example process 300shown in FIG. 3. The devices 402 a, 402 b may communicate based onadditional or different techniques.

FIG. 4C shows the example process 400 c for establishing a shared secretbetween the devices 402 a and 402 b. In the example process 400 c shownin FIG. 4C, the devices 402 a and 402 b each include an NFC interface.Moreover, the devices 402 a, 402 b are both configured to receivecertificate data from a certificate authority 430. In someimplementations, the certificate authority 430 can be a certificateauthority module implemented by one of the devices 402 a, 402 b. In someimplementations, the certificate authority 430 can be a certificateauthority module implemented by another device (e.g., a remote or localdevice). One or both of the devices 402 a, 402 b may be configured tocommunicate with the certificate authority over a communication link.The communication link may include one or more wired or wireless links,one or more data networks, or a combination of these and other types ofdata connections. The devices 402 a, 402 b may include additional ordifferent features or components, as appropriate.

At 432 a and 432 b, the first device 402 a and the second device 402 beach obtain certificate data from the certificate authority 430. Thecertificate data can include one or more digital certificates issued bythe certificate authority 430. One or both of the devices 402 a, 402 bmay receive the certificate data by a wired or wireless connection toanother device, over a network, or otherwise. In some implementations,one of the devices 402 a, 402 b can act as the certificate authority430. Accordingly, a certificate may be obtained by accessing thecertificate from a local memory, generating the certificate locally onthe device, or in another manner. In some implementations, the devices402 a, 402 b obtain all or part of the certificate data from each other,for example, by exchanging digital certificates.

The certificate data obtained by the devices 402 a, 402 b can includeone or more digital certificates. Generally, a digital certificatecertifies a particular public key associated with a device or userentity, and may also certify that the device or user entity haspossession of a private key corresponding to the certified public key.In some examples, the first device 402 a obtains a certificatecontaining the public key of the second device 402 b, and the seconddevice 402 b obtains a certificate containing the public key of thefirst device 402 a. The digital certificates can include implicitcertificates, explicit certificates, or other types of digitalcertificates. Examples of conventional digital certificates includeX.509 certificates, Elliptic Curve Qu Vanstone (ECQV) implicitcertificates, and others.

One or more devices owned or managed by the same entity may beconfigured to perform the duties of a certificate authority for a subsetof other devices under control of the same entity. In someimplementations, a mobile device can act as a root certificateauthority, a subordinate certificate authority, or another type ofcertificate authority. For example, a secondary certificate authoritycan be chained to a root certificate authority, and the secondarycertificate authority can issue certificates to other devices. Forexample, if the owner of the a mobile device has its own certificateauthority, then the mobile device can be configured to issuecertificates to other devices that it trusts.

At 434, the first device 402 a and the second device 402 b execute a keyagreement protocol. For example, the key agreement protocol can use thecertificate data to establish a shared secret for NFC communications. Insome cases, the key agreement protocol can include operations performedlocally by the devices 402 a, 402 b and operations that requirecorrespondence between the devices 402 a, 402 b. The correspondence canbe executed over any suitable type of data link or connection betweenthe devices. As a result of executing the key agreement protocol, ashared secret value can be stored at the first device 402 a and thesecond device 402 b. The key agreement protocol can be executed in amanner that prevents or reduces the likelihood of an eavesdropperobtaining the shared secret.

The key agreement protocol can include operations based on thecertificate data obtained by the first device 402 a and the seconddevice 402 b. For example, the key agreement protocol may utilize thepublic and private keys associated with one or more digitalcertificates. The key agreement protocol may include operationsperformed by a pseudorandom generator, a cryptographic processing unit,or other types of modules on the devices 402 a, 402 b. Any suitable keyagreement protocol can be used. In some implementations, a standardizedkey agreement protocol is used. Example key agreement protocols includethe Diffie-Hellman key agreement protocol, the Elliptic Curve Menezes QuVanstone (EC MQV) key agreement protocol, the HMQV key agreementprotocol, and others.

At 436, the NFC interface 404 a of the first device 402 a and the NFCinterface 404 b of the second device 402 b can exchange messages andintegrity data. In some implementations, the devices 402 a, 402 b canexchange messages and integrity data as described with respect tooperation 416 shown in FIG. 4A. For example, having established a sharedsecret based on the certificates provided by the certificate authority430, the devices 402 a, 402 b can generate integrity data for messagesto be exchanged over NFC. The integrity data can include, for example,an authentication value based on the shared secret. The integrity datacan additionally include a timestamp value, for example, indicating whenthe authentication value was generated, or another relevant time. Insome implementations, the devices 402 a, 402 b shown in FIG. 4C cancommunicate based on one or more operations of the example process 300shown in FIG. 3. The devices 402 a, 402 b may communicate based onadditional or different techniques.

The operations described in this specification can be implemented asoperations performed by a data processing apparatus on data stored onone or more computer-readable storage devices or received from othersources. The term “data processing apparatus” encompasses all kinds ofapparatus, devices, and machines for processing data, including by wayof example a programmable processor, a computer, a system on a chip, ormultiple ones, or combinations, of the foregoing. The apparatus caninclude special purpose logic circuitry, e.g., an FPGA (fieldprogrammable gate array) or an ASIC (application-specific integratedcircuit). The apparatus can also include, in addition to hardware, codethat creates an execution environment for the computer program inquestion, e.g., code that constitutes processor firmware, a protocolstack, a database management system, an operating system, across-platform runtime environment, a virtual machine, or a combinationof one or more of them.

A computer program (also known as a program, software, softwareapplication, script, or code) can be written in any form of programminglanguage, including compiled or interpreted languages, declarative orprocedural languages, and it can be deployed in any form, including as astand-alone program or as a module, component, subroutine, object, orother unit suitable for use in a computing environment. A computerprogram may, but need not, correspond to a file in a file system. Aprogram can be stored in a portion of a file that holds other programsor data (e.g., one or more scripts stored in a markup languagedocument), in a single file dedicated to the program in question, or inmultiple coordinated files (e.g., files that store one or more modules,sub-programs, or portions of code). A computer program can be deployedto be executed on one computing device or on multiple computers that arelocated at one site or distributed across multiple sites andinterconnected by a communication network.

The processes and logic flows described in this specification can beperformed by one or more programmable processors executing one or morecomputer programs to perform actions by operating on input data andgenerating output. The processes and logic flows can also be performedby, and apparatus can also be implemented as, special purpose logiccircuitry, e.g., an FPGA (field programmable gate array) or an ASIC(application-specific integrated circuit).

Processors suitable for the execution of a computer program include, byway of example, both general and special purpose microprocessors, andany one or more processors of any kind of digital computing device.Generally, a processor will receive instructions and data from aread-only memory or a random access memory or both. A computing devicetypically includes a processor for performing actions in accordance withinstructions and one or more memory devices for storing instructions anddata. Generally, a computing device will also include, or be operativelycoupled to receive data from or transfer data to, or both, one or morestorage devices for storing data. However, a computing device need nothave such devices. Moreover, a computer can be embedded in anotherdevice, e.g., a mobile telephone, a personal digital assistant (PDA), amobile audio or video player, a game console, a Global PositioningSystem (GPS) receiver, or a portable storage device (e.g., a universalserial bus (USB) flash drive), to name just a few. Devices suitable forstoring computer program instructions and data include all forms ofnon-volatile memory, media and memory devices, including by way ofexample semiconductor memory devices, e.g., EPROM, EEPROM, and flashmemory devices; magnetic disks, e.g., internal hard disks or removabledisks; magneto-optical disks; and CD-ROM and DVD-ROM disks. Theprocessor and the memory can be supplemented by, or incorporated in,special purpose logic circuitry.

To provide for interaction with a user, subject matter described in thisspecification can be implemented on a computer having a display device,e.g., an LCD (liquid crystal display) screen for displaying informationto the user and a keyboard and a pointing device, e.g., touch screen,stylus, mouse, etc. by which the user can provide input to the computer.Other kinds of devices can be used to provide for interaction with auser as well; for example, feedback provided to the user can be any formof sensory feedback, e.g., visual feedback, auditory feedback, ortactile feedback; and input from the user can be received in any form,including acoustic, speech, or tactile input.

Similarly, while operations are depicted in the drawings in a particularorder, this should not be understood as requiring that such operationsbe performed in the particular order shown or in sequential order, orthat all illustrated operations be performed, to achieve desirableresults. In certain circumstances, multitasking and parallel processingmay be advantageous. Moreover, the separation of various systemcomponents in the implementations described above should not beunderstood as requiring such separation in all implementations, and itshould be understood that the described program components and systemscan generally be integrated together in a single software product orpackaged into multiple software products.

In a general aspect, data integrity is provided for wirelesscommunication between mobile devices. For example, the mobile devicesmay communicate by a Near Field Communication (NFC) interface or anothertype of proximity-activated wireless interface.

In some aspects, a message is accessed at a first mobile device. Ashared secret value associated with a second mobile device is accessedat the first mobile device. An authentication value is generated at thefirst mobile device based on the message and the shared secret value.Proximity of the second mobile device is detected at the first mobiledevice. In response to detecting proximity of the second mobile device,the message and the authentication value are wirelessly transmitted fromthe first mobile device directly to the second mobile device.

Implementations of these and other aspects can include one or more ofthe following features. Detecting proximity of the second mobile deviceincludes detecting proximity of the second mobile device by aproximity-activated wireless interface of the first mobile device. Theproximity-activated wireless interface includes a Near FieldCommunication (NFC) interface. The message and the authentication valueare wirelessly transmitted by the proximity-activated wirelessinterface. Wirelessly transmitting the message and the authenticationvalue from the first mobile device directly to the second mobile deviceincludes wirelessly transmitting the message and the authenticationvalue from a mobile telecommunication device directly to a tablet deviceby a proximity-activated wireless interface.

Additionally or alternatively, implementations of these and otheraspects can include one or more of the following features. The sharedsecret value is established between the first mobile device and thesecond mobile device. The first mobile device includes a first wirelesscommunication module and a second wireless communication module. Themessage and the authentication value are wirelessly transmitted from thefirst mobile device by the first wireless communication module. Theshared secret value is established based in part on transmitting datafrom the first mobile device by the second wireless communicationmodule. The first wireless communication module transmits wirelesssignals at a frequency of 13.56 MHz, and the second wirelesscommunication module transmits wireless signals at a second frequency inthe range of 2400 MHz to 2480 MHz. The first wireless communicationmodule transmits wireless signals at a frequency of 13.56 MHz, and thesecond wireless communication module transmits wireless signals at asecond frequency greater than 1 GHz.

Additionally or alternatively, implementations of these and otheraspects can include one or more of the following features. The sharedsecret value is established between the first mobile device and thesecond mobile device. The first mobile device includes a user interface.Establishing the shared secret value includes receiving the sharedsecret value at the first mobile device based on a user interaction withthe user interface. Establishing the shared secret value includesaccessing, at the first mobile device, a certificate issued by acertificate authority. Establishing the shared secret includes derivingthe shared secret at the first mobile device based on the certificate.

Additionally or alternatively, implementations of these and otheraspects can include one or more of the following features. Theauthentication value is generated by evaluating a keyed hashingalgorithm based on the message and the shared secret value. Generatingthe authentication value includes generating a Message AuthenticationCode (MAC) by evaluating a keyed Hash-based Message Authentication Code(HMAC) algorithm based on the message and the shared secret value. TheMAC is appended to the message at the first mobile device. A timestampvalue associated with the authentication value is generated. Thetimestamp value is wirelessly transmitted from the first mobile devicedirectly to the second mobile device. The timestamp value and theauthentication value are appended to the message at the first mobiledevice.

Thus, particular implementations of the subject matter have beendescribed. Other implementations are within the scope of the followingclaims. In some cases, the actions recited in the claims can beperformed in a different order and still achieve desirable results. Inaddition, the processes depicted in the accompanying figures do notnecessarily require the particular order shown, or sequential order, toachieve desirable results. In certain implementations, multitasking andparallel processing may be advantageous.

What is claimed is:
 1. A method for trusted communication among mobiledevices, the method comprising: accessing a message at a first mobiledevice; accessing a shared secret value stored at the first mobiledevice and associated with a second mobile device; generating anauthentication value at the first mobile device based on the message andthe shared secret value; detecting proximity of the second mobile deviceat the first mobile device; and in response to detecting proximity ofthe second mobile device, wirelessly transmitting the message and theauthentication value from the first mobile device directly to the secondmobile device.
 2. The method of claim 1, wherein detecting proximity ofthe second mobile device comprises detecting proximity of the secondmobile device by a proximity-activated wireless interface of the firstmobile device.
 3. The method of claim 2, wherein the proximity-activatedwireless interface comprises a Near Field Communication (NFC) interface.4. The method of claim 2, wherein the message and the authenticationvalue are wirelessly transmitted by the proximity-activated wirelessinterface.
 5. The method of claim 1, wherein wirelessly transmitting themessage and the authentication value from the first mobile devicedirectly to the second mobile device comprises wirelessly transmittingthe message and the authentication value from a mobile telecommunicationdevice directly to a tablet device by a proximity-activated wirelessinterface.
 6. The method of claim 1, further comprising establishing theshared secret value between the first mobile device and the secondmobile device.
 7. The method of claim 6, wherein the first mobile deviceincludes a user interface, and establishing the shared secret valuebetween the first mobile device and the second mobile device includesreceiving the shared secret value at the first mobile device based on auser interaction with the user interface.
 8. The method of claim 6,wherein the first mobile device includes a first wireless communicationmodule and a second wireless communication module, and wherein themessage and the authentication value are wirelessly transmitted from thefirst mobile device by the first wireless communication module, and theshared secret value is established based in part on transmitting datafrom the first mobile device by the second wireless communicationmodule.
 9. The method of claim 8, wherein the first wirelesscommunication module transmits wireless signals at a frequency of 13.56MHz, and the second wireless communication module transmits wirelesssignals at a second frequency in a range of 2400 MHz to 2480 MHz. 10.The method of claim 8, wherein the first wireless communication moduletransmits wireless signals at a frequency of 13.56 MHz, and the secondwireless communication module transmits wireless signals at a secondfrequency greater than 1 GHz.
 11. The method of claim 6, whereinestablishing the shared secret value between the first mobile device andthe second mobile device includes: accessing, at the first mobiledevice, a certificate issued by a certificate authority; and derivingthe shared secret at the first mobile device based on the certificate.12. The method of claim 1, wherein the authentication value is generatedby evaluating a keyed hashing algorithm based on the message and theshared secret value.
 13. The method of claim 1, wherein generating theauthentication value comprises generating a Message Authentication Code(MAC) by evaluating a keyed Hash-based Message Authentication Code(HMAC) algorithm based on the message and the shared secret value, andthe method further comprises appending the MAC to the message at thefirst mobile device.
 14. The method of claim 1, further comprising:generating a timestamp value associated with the authentication value;and wirelessly transmitting the timestamp value from the first mobiledevice directly to the second mobile device.
 15. The method of claim 14,further comprising appending the timestamp value and the authenticationvalue to the message at the first mobile device.
 16. A mobile devicecomprising: memory operable to store a shared secret value; a wirelesscommunication interface; data processing apparatus operable to performoperations comprising: detecting proximity of a second mobile device;generating an authentication value based on a message and the sharedsecret value; and in response to detecting proximity of the secondmobile device, wirelessly transmitting, by the wireless communicationinterface, the message and the authentication value directly to thesecond mobile device.
 17. The mobile device of claim 16, wherein thewireless communication interface includes a Near Field Communication(NFC) interface.
 18. The mobile device of claim 17, wherein the messageand the authentication value are wirelessly transmitted by the NFCinterface.
 19. The mobile device of claim 16, wherein the mobile deviceincludes a first wireless communication module comprising the wirelesscommunication interface, wherein the first wireless communication moduleis operable to communicate with the second mobile device by wirelesssignals in a first frequency range, and the mobile device furthercomprises a second wireless communication module operable to communicatewith the second mobile device by wireless signals in a second frequencyrange.
 20. The mobile device of claim 16, wherein the authenticationvalue is generated by evaluating a keyed hashing algorithm based on themessage and the shared secret value.
 21. The mobile device of claim 16,wherein generating the authentication value comprises generating aMessage Authentication Code (MAC) by evaluating a keyed Hash-basedMessage Authentication Code (HMAC) algorithm based on the message andthe shared secret value.
 22. The mobile device of claim 16, theoperations further comprising: generating a timestamp value associatedwith the authentication value; and wirelessly transmitting the timestampvalue directly to the second mobile device.
 23. The mobile device ofclaim 16, wherein the mobile device comprises a mobile telecommunicationhandset.
 24. The mobile device of claim 16, wherein the mobile devicecomprises a tablet device.
 25. A non-transitory computer-readable mediumstoring instructions that are operable when executed by data processingapparatus to perform operations for trusted communication among mobiledevices, the operations comprising: accessing a message at a firstmobile device; accessing a shared secret value stored at the firstmobile device and associated with a second mobile device; generating anauthentication value at the first mobile device based on the message andthe shared secret value; detecting proximity of the second mobile deviceat the first mobile device; and in response to detecting proximity ofthe second mobile device, wirelessly transmitting the message and theauthentication value from the first mobile device directly to the secondmobile device.
 26. The computer-readable medium of claim 25, whereindetecting proximity of the second mobile device comprises detectingproximity of the second mobile device by a proximity-activated wirelessinterface of the first mobile device.
 27. The computer-readable mediumof claim 26, wherein the proximity-activated wireless interfacecomprises a Near Field Communication (NFC) interface.
 28. Thecomputer-readable medium of claim 26, wherein the message and theauthentication value are wirelessly transmitted by theproximity-activated wireless interface.
 29. The computer-readable mediumof claim 25, further comprising establishing the shared secret valuebetween the first mobile device and the second mobile device.
 30. Thecomputer-readable medium of claim 29, wherein the first mobile deviceincludes a user interface, and establishing the shared secret valuebetween the first mobile device and the second mobile device includesreceiving the shared secret value at the first mobile device based on auser interaction with the user interface.
 31. The computer-readablemedium of claim 29, wherein the first mobile device includes a firstwireless communication module and a second wireless communicationmodule, and wherein the message and the authentication value arewirelessly transmitted from the first mobile device by the firstwireless communication module, and the shared secret value isestablished based in part on transmitting data from the first mobiledevice by the second wireless communication module.
 32. Thecomputer-readable medium of claim 25, wherein establishing the sharedsecret value between the first mobile device and the second mobiledevice includes: accessing, at the first mobile device, a certificateissued by a certificate authority; and deriving the shared secret at thefirst mobile device based on the certificate.
 33. The computer-readablemedium of claim 25, wherein the authentication value is generated byevaluating a keyed hashing algorithm based on the message and the sharedsecret value.
 34. The computer-readable medium of claim 25, theoperations further comprising: generating a timestamp value associatedwith the authentication value; and wirelessly transmitting the timestampvalue from the first mobile device directly to the second mobile device.